What

ParsedDockerfile treats every FROM line's first non-flag token as an external image to pre-pull. In a multi-stage Dockerfile, a FROM referencing a previously declared build stage is an internal reference, not an external image:

FROM alpine:3.17 AS build
RUN ...
FROM build

Before this change, getDependencyImageNames() returned {alpine:3.17, build}, and Testcontainers attempted to pull an image named build from the registry.

Impact of the broken behaviour

• A pointless registry roundtrip per stage reference, which also counts against Docker Hub pull rate limits, and a confusing WARN/retry in the logs when the phantom image does not exist.
• If the stage alias happens to collide with a real image name on Docker Hub (e.g. build, test, base), an unrelated image is actually pulled.

The build itself succeeded despite this, so this is about spurious network traffic and log noise rather than failures.

How it is fixed

• The FROM line pattern now also captures an optional AS <stage> alias (case-insensitively, matching Docker's semantics).
• parse() collects declared stage names and skips FROM images that reference a previously declared stage. Ordering follows Docker semantics: an alias only shadows an image name after the stage is declared.

Existing behaviour is preserved: --platform/other flags (#2772), tags, digests, trailing content after the image, and stages whose alias is never referenced are all still handled as before; COPY --from=<stage> lines were never matched and still are not.

Tests

Added unit tests covering: a stage referenced by a later FROM (fails without the fix with expected: ["alpine:3.17"] but was: ["build", "alpine:3.17"]), a typical maven/eclipse-temurin multi-stage file, case-insensitive stage name matching, and unreferenced stage aliases.